Determination of network delays has been important since the early days of packet networking. When data transfers exceed the expected time or are delayed so much as to impair utility, network operators and network users have sought ways to track down that delay. As network usage has evolved to include more delay sensitive applications, monitoring network delay has become increasingly important.
The delay experienced by a packet traversing a network consists of intrinsic delay, the minimum time packet transport takes, and queuing delay, the time spent waiting for resources due to other packets in the network. Queuing delay is a measure of a network's congestion and thus an important metric to users and operators of networks. Current approaches to estimating and isolating network delays rely on one or more of the following: injecting additional active measurement traffic into the network, sophisticated clock synchronization, or the ability to capture and pair packets traveling in both directions between endpoints. These approaches have drawbacks that include perturbing the actual delay, requiring additional hardware, implementation complexity, being unusable where both directions of a communication are not readily available, and being unable to continuously monitor the actual delays experienced by network packets.
Most delay estimation approaches inject packets into a network (e.g. “active measurement”) or require cooperation of two communicating entities. Active measurement impacts the quantity it is attempting to measure by adding more traffic to the network, which generally increases delay. Further, this only samples the delay based on the network conditions experienced by the injected packet and thus the sampling methodology is important. To minimize network and host impact, active measurement is usually carried out for brief periods of time, generally when a problem is being experienced. Passive techniques can run continually and data can be examined over a range of conditions and times of day.
Passive techniques for estimating the round-trip delay between two communicating end points have long been included with network transport protocols. The round-trip delay only needs to rely on the clock at one end point, so no clock synchronization is needed. These estimates are used internally to a particular host's transport protocol and are not used as general estimates of network delay.
The problem of passively estimating the path segments within the round trip is more complicated due to clock offsets, drift, and skew. Current approaches include synchronized clocks using hardware, which can be quite complex and limits deployment and use of Network Time Protocol, which can lack precision and requires cooperating endpoints. Passive measurements that require cooperating endpoints are limited to measuring network paths between those end-points and these may not include the delays that were impacting a particular use of the network. Passive techniques for determining path segment delay exist that depend on matching specific bidirectional packet pairs of the flow. Packet pairing techniques are vulnerable to packet loss and multipathing and must be deployed where both directions of a flow are forced to pass.